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Abstract. There are a number of approaches for eliminating intermedi¬ 
ate data structures in functional programs—this elimination is commonly 
known as fusion. Existing fusion strategies are built upon various, but 
related, recursion schemes, such as folds and unfolds. We use the concept 
of recursive coalgebras as a unifying theoretical and notational framework 
to explore the foundations of these fusion techniques. We first introduce 
the calculational properties of recursive coalgebras and demonstrate their 
use with proofs and derivations in a calculational style, then provide an 
overview of fusion techniques by bringing them together in this setting. 
We also showcase these developments with examples in Haskell. 


1 Introduction 

Functional programmers love modular programs. It is easy for them to create 
clear, concise, and reusable code by composing functions. Consider the following 
Haskell program as an example: 


/ : ( Integer , Integer) —> Integer 
f = sum ■ map sq ■ filter odd ■ between . 

The program takes a pair of integers representing an interval and returns the 
sum of the squared odd integers in this interval. We have expressed this a compo¬ 
sition of four functions: between generates an enumeration between two natural 
numbers as a list, filter odd removes any even numbers, map sq squares the re¬ 
maining (odd) numbers, and sum adds them together. Unfortunately, the clarity 
of this program comes at a cost. The constituent functions of this program com¬ 
municate with each other using intermediate data structures, the production and 
immediate consumption of which carries an obvious performance penalty. Yet, 
because these definitions are recursive, eliminating the need for these transient 
structures is beyond the reach of a typical compiler. 

Nonetheless, such a transformation is possible. We can manually construct a 
program that is equivalent to /, but without the intermediate data structures 

f{m,n) = go m 

where go m \ m > n =0 

| otherwise = go (m + 1) + if odd m then sq m else 0 . 
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This new program has lost the desirable qualities of the original—our concise, 
modular and declarative code has been hammered into a long, opaque and spe¬ 
cialised function. In doing so, however, we have accomplished our goal of remov¬ 
ing the intermediate data structures by transforming the numerous recursive 
traversals into a single one. This process is called fusion. 

Fusing programs by hand quickly becomes infeasible for those of non-trivial 
length. Furthermore, it can be difficult to manually pinpoint all the opportunities 
for fusion. Instead, such a transformation should be performed automatically. 
Difficulties arise, however, in automatically fusing functions defined using general 
recursion. Specifically, such transformations often have proof obligations that 
cannot be discharged by the compiler. 

One remedy is to standardise the way data structures are produced or con¬ 
sumed by encapsulating the recursion scheme in a higher-order function. The ar¬ 
guments to these functions are the non-recursive ‘steps’. Simple syntactic trans¬ 
formations can then fuse many recursive traversals into a single one, and then 
non-recursive steps can be optimised using conventional methods. This approach 
is known as shortcut fusion. Different incarnations of this technique utilise dif¬ 
ferent recursion schemes, e.g. folds for consumers or unfolds for producers. The 
steps of such a scheme are known as algebras or coalgebras, respectively. 

The implementation of these fusion techniques is usually described syntacti¬ 
cally, by giving a definition of the production and consumption combinators and 
accompanying rewrite rules. This alone does not really explain the underlying 
fusion mechanism. Furthermore, it is difficult to construct correctness proofs, 
or relate various fusion approaches to one another, despite the fact that such 
close relations exist. In this paper, we move fusion to a clearer setting, where 
the syntactic details of fusion fall away. 

Category theory provides the tools we need to tackle the semantics of the 
recursion schemes. While some fusion techniques have been individually given 
this treatment before, our focus is to bring them all under one roof. In this paper, 
we propose using recursive coalgebras as that roof. We will show how recursive 
coalgebras enable us to explain the fusion rules underlying the various fusion 
techniques and give short, simple proofs of correctness. 

Some proofs and source code examples have been elided from this paper. 
Any reader who desires further material should consult the associated technical 
report [10]. 

2 Background: Algebras and Coalgebras 

The category theory concept of an initial algebra is key in the theory of func¬ 
tional programming languages, specifically for giving a semantics to recursive 
datatypes [15]. The remainder of this section will refresh the salient details. For 
the more functional-programming-minded reader, we will parallel these develop¬ 
ments with examples in Haskell, where possible. 

Let F : C —> C be a functor. An F-algebra is a pair (a, A) consisting of an ob¬ 
ject A : C and an arrow a : F A —> A : C. An F-algebra homomorphism between 
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algebras (a, A) and (ft, B) is an arrow ft : A —> B : C such that h ■ a = b ■ F ft. 
The fact that functors preserve identity and composition entails that identity is 
a homomorphism and that homomorphisms compose. Consequently, F-algebras 
and their homomorphisms form a category, called Alg(F). We abbreviate a ho¬ 
momorphism, ft : (a, A) —> ( b,B } : Alg(F), by ft : a —* b : Alg(F) if the objects 
are obvious from the context, or simply by h : a —> b if the functor F is also 
obvious. 

In Haskell, we model a functor as a datatype whose constructors describe its 
action on data (i.e. objects). Its action on arrows is defined by making that data 
type an instance of the Functor typeclass 

class Functor f where 
fmap : (a -> 6) -> (/ a -> / 6) . 

We can then simply treat the concept of an F-algebra as a function, where F is a 
datatype that is an instance of the Functor class. The F-algebra (a, A) is simply a 
function a : F A —* A. An F-algebra homomorphism between a and 6 : F B —> B 
is a function ft : A —> B that satisfies the side condition ft ■ a = b ■ fmap ft. This 
property cannot, however, be deduced from the type and must be checked by 
the programmer. 

If the category Alg(F) has an initial object, then we call it (in, pf). Initially 
means that there is a unique arrow from (in,p F) to any other F-algebra (a, A). 
This arrow, called fold, is written (|a) : in —> a. We construct elements of 
/iF using in and deconstruct them using (|a[). We can think of d«D : ' m a 
as replacing constructors by functions, represented by the algebras in and a, 
respectively. Initiality is captured by the uniqueness property of folds: 1 

ft = da) ft : in —> a ft • in = a ■ Fft . (1) 

It is important to note that we have omitted the quantification of the names that 
appear in property (1); we have done so for presentational succinctness and we 
will continue in this manner. In this case we will spell out implicit quantification: 
the uniqueness property holds for all functors F, where the category Alg(F) has 
an initial object named (in,p F), and for all F-algebras (a, A), and for all F- 
algebra homomorphisms ft : in —> a. 

This property provides us with a general definition of d~) in Haskell. First, 
we define the p datatype, which takes a functor to its least fixed point: 

data pf = in { out : f (pf )} 

The constructor in allows us to construct a structure of type pf out of something 
of type / (pf) and out deconstructs it. The relationship between in and out in 
our setting is discussed further in Sections 3 and 4. 


1 The formula P <*=> Q R has to be read conjunctively as P <*=> Q A Q <*=> R. 
Likewise, P i=sB;Q R is shorthand for P <= Q A Q <*=> R. 
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We can define (| — D as a higher-order function that takes an algebra / a —> a 
and returns a function pf a , according to the uniqueness property: 

(H : (Functorf) => (/ a -> a) -> (pf -*■ a) 

daD = a ’ f ma P d«D ’ out 

By allowing us to substitute (as) f° r h, we see that the uniqueness property 
provides us with a definition of d — D that recursively replaces occurrences of in 
by some algebra a. The placement of the recursive call for a given structure pf 
is determined by the definition fmap. 

We will not employ the uniqueness property in an example proof just yet. In 
fact the uniqueness property is rarely used in its raw form; instead, there are a 
number of specific forms that we will introduce now. 

If we set h to the identity id and a to the initial algebra in, then we obtain 
the reflection law : (m) = id- If we substitute the left-hand side into the right- 
hand side, then we obtain the computation law: m) : in —> a, or expressed in 
terms of the base category, |^| • in = a ■ F ((a). 

The most important consequence of the uniqueness property is the fusion 
law for fusing an arrow with a fold to form a new fold. 

/i-4ft§ = d&D ## h:a^b h-a = b-Fh (2) 

As its name would suggest, the fusion law is closely related to the program trans¬ 
formation techniques described in the introduction. It allows a fold to absorb a 
function on its left, thereby producing a single fold. The law also shows the dif¬ 
ficulty of mechanising this process; in order to produce the fused program, we 
must invent a new algebra b that satisfies the precondition. 

Folds enjoy an additional fusion law. Whereas fusion allows us to absorb an 
additional function on the left, the functor fusion law allows us to absorb a 
function on the right. In order to formulate it, we have to turn p into a higher- 
order functor of type C c —» C. The object part of this functor maps a functor 
to its initial algebra. (This is only well-defined for functors that have an initial 
algebra.) The arrow part maps a natural transformation a : F -4 G to an arrow 
pa : pF —> pG : C. It is defined as pa = (\m ■ a (pF) [). To reduce clutter, we 
will henceforth omit the argument of the natural transformation a. From these 
definitions we obtain the functor fusion law (we have annotated ( — ) with the 
underlying functors): 

<\b\) Q -pa = (| 6 • as) F . (3) 

It states that a fold after a map can be fused into a single fold — the map pa 
can be seen as a “base changer”. 

We can also provide a Haskell definition of p as a functor. The action on data 
is given by its datatype declaration. The action on functions is given by: 

p- : (Functor /) => (V a . f a -> g a) -> (pf -> pg) 

pa = <\in ■ a) 

Note that we use a rank-2 polymorphic type to express the idea that p maps 
natural transformation from / to g to a function between their fixpoints. 
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Finally, the initial algebra /xF is the least fixed point of F — this is known 
as Lambek’s Lemma [13]. One direction of the isomorphism F (/xF) = /xF is 
given by in, its inverse is in° = (Fin). Lambek’s Lemma is the key to giving 
a semantics to recursively defined datatypes. To illustrate this, the recursive 
definition of lists of natural numbers 

data List = Nil \ Cons (N, List) 

implicitly defines an underlying functor LL = 1 + Nx I, the so-called base 
functor of List. (This notation is a categorical rendering of sum-of-products al¬ 
gebraic datatypes, and defines a functor L with an argument X , where 1 denotes 
the terminal object of the underlying category.) Since the initial object /xL sat¬ 
isfies the equation X = LX, we can use it to assign meaning to the recursive 
datatype definition. (As an aside, the fold of the List datatype is a specialisation 
of Haskell’s library function foldr.) 

The initial F-algebra is the least solution of the equation X = FX. If we 
dualise the development above, we obtain another canonical solution, namely 
the greatest one. In category theory, dualisation is denoted by the prefix “co-”. 

An F -coalgebra is a pair (C, c) consisting of an object C : C and an arrow 
c : C —> F C : C. An F -coalgebra homomorphism between coalgebras ( C , c) and 
(D, d) is an arrow h : C —> D : C such that F h ■ c = d ■ h. Coalgebras and 
coalgebra homomorphisms also form a category, called Coalg(F). The dual of 
the initial algebra is the final coalgebra, whose carrier vF is the greatest fixed 
point of F. Finality means that, for any other coalgebra, there is a unique arrow 
from it to the final coalgebra. Whereas a fold consumes a data structure, an 
unfold produces some data structure from a given seed. 

Unfortunately, least and greatest fixed points are different beasts in general. 
In the category Set of sets and total functions, /xL is the set of finite lists, 
whereas oL also contains infinite lists. This means that folds and unfolds are 
incompatible, in general. In the following section, we will focus on a restricted 
species of coalgebras, enabling us to work with folds and unfolds under the same 
roof. 

3 Recursive Coalgebras 

In this section we will introduce recursive coalgebras. We follow the work of 
Capretta et al. [2], who motivate the use of hylomorphisms based on recursive 
coalgebras as a structured recursion scheme. We shall continue to parallel our 
developments with examples in Haskell. 

A coalgebra (C, c) is called recursive if for every algebra {a, A) the equation 
in the unknown h : A <— C, 

h = a-Fh-c , (4) 

has a unique solution. The equation captures divide-and-conquer-, a problem is 
divided into sub-problems (c), the sub-problems are solved recursively (F ft), and 
finally the sub-solutions are combined into a single solution (a). The uniquely 
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defined function h is called a hylomorphism or hylo for short and is written 
(|a <— cD F : A <— C. The notation is meant to suggest that h takes a coalgebra 
to an algebra. We omit the subscripted functor name if it is obvious from the 
context. Uniqueness of h is captured by the following property. 

h = <\a <— cD <*=> h = a-Fh- c (5) 

In Haskell, fl — <-D becomes a function that takes an algebra and a recursive 

coalgebra (which, dual to algebras, is a function of type c —> / c) as arguments 
and returns resulting hylo according to the definition in the universal property: 

d~ <-D : ( Functorf) => (/ a -> a) -> (c -*■ / c) -> (c -> a) 

(ja <- cD = a • fmap (ja <- cD • c . 

This function takes an algebra and a recursive coalgebra, yielding a hylo. Note 
that the type of this function does not guarantee that c is a recursive coalgebra 
and therefore does not guarantee that the resulting hylo has a unique solution; 
the programmer needs to discharge this obligation by some other means. 

The category of recursive coalgebras and coalgebra homomorphisms forms a 
full subcategory of Coalg(F), called Rec(F). If the latter category has a final 
object (F, out), then there is a unique arrow from any other recursive coalgebra 
(C, c) to (F, out). This arrow, called unfold, is written [cj : c —> out. Finality is 
captured by the following uniqueness property. 

h = |cj <*==> h : c —* out <*=> F h ■ c = out ■ h (6) 

This is the usual property of unfolds, except that we are working in the category 
Rec(F), not Coalg(F). As with folds, we can draw out a Haskell definition of 
unfolds from the uniqueness property: 

[-] : (Functor /) => (c -> / c) -> (c -*■ pf) 

[c] = in ■ fmap{cj ■ c . 

In contrast to folds, we are creating a structure of type pf from a seed value. 
The recursion, similarly, is determined by the form of the underlying functor / 
through the use of fmap. The uniqueness property for unfolds, like the one for 
folds, implies the reflection law, [owf] = id, the computation law, F[c] • c = 
out ■ [c], and the fusion law: 

[cj] = [d] • h <= h:c^d <^=> F h-c=d-h. (7) 

The definition of a hylomorphism does not assume that the initial F-algebra 
exists. The powerset functor, for instance, admits no fixed points. However, if 
the initial algebra exists, then it coincides with the final recursive coalgebra and, 
furthermore, folds and unfolds emerge as special cases of hylos. We can state this 
more formally: 

Theorem 1. Initial F-algebras and final recursive F-coalgebras coincide: (I) If 
(C, out) is the final recursive F-coalgebra, then (out°, C) is the initial F-algebra. 
Furthermore, (a|) = (a <— out D- (2) If (in, A) is the initial F-algebra, then 
(A,in °} is the final recursive F-coalgebra. Furthermore, [c] == <]m <— c|). 
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Theorem 1 allows us to treat folds and unfolds in the same setting—note that 
an unfold produces an element of an initial algebra! An alternative is to work in 
a setting where p F and z^F coincide; an algebraically compact category is such 
a setting [8]. Haskell’s ambient category Cpo ± serves as the standard example. 
This is the usual approach [7], however, the downside is that the hylo equation (4) 
only has a canonical, least solution, not a unique solution, so (5) does not hold. 

4 Calculational Properties 

In this section we will cover the calculational properties of our hylomorphisms. 
In a similar fashion to folds and unfolds, hylomorphisms have an identity law and 
a computation law, and they follow similarly from the uniqueness property (5). 
Identity law Setting h := id, we obtain the identity law 

(|a <— cD = id <<=>■ a ■ c = id . (8) 

Computation law Substituting the left-hand side into the right-hand side gives 
the computation law: 

(a <—c) = a • F da <—cj) • c . (9) 

For hylomorphisms, we have three fusion laws: algebra fusion, coalgebra fusion, 
and composition. 

Algebra fusion An algebra homomorphism after a hylo can be fused to form 
a single hylo. 2 

h ■ d« <- c) = (b<-c) <= h : a —> b <^=> h-a=b-Fh (10) 

For the proof we appeal to the uniqueness property and show that h ■ d a <— e| 
satisfies the recursion equation of <\b <— c|). The obligation is discharged as 
follows: 

h • d a <- cj$: 

= { hylo computation (9) } 

ft • a • F (a • c)-c 
= { assumption: h : a —* 6 } 

6 • F A - F da ^ c|) - c 
= { F functor } 

6 • F(ft • (a *— c)) • c . 

Coalgebra fusion Dually, we can fuse a coalgebra homomorphism 
to form a single hylo. 

(a <—c) = (a <—d) • ft h : c—> d Fh-c = 

2 Note that ft appears as both an algebra homomorphism in Alg(F) and as the un¬ 
derlying arrow in the underlying category. 


before a hylo 
d- ft (11) 
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Like the law, the proof is the dual of that for algebra fusion. 

Composition law A composition of hylos can be merged into a single one if 
the coalgebra of the hylo on the left inverts the algebra of the right hylo. 

(|a <— cD • <\b <- 4 = d a ft <= c ■ b = id (12) 

Composition is, in fact, a simple consequence of algebra fusion as the hylomor- 
phism da <— c) : b —> a is simultaneously an F-algebra homomorphism. 

da <— c) • 6 

= { hylo computation (9) } 

a • F da <— c) • c • 6 
= { assumption: c ■ b = id } 

a • F da <— c) 

Alternatively, we can derive the composition law from coalgebra fusion by show¬ 
ing that <\b <— d) : d —> c is an F-coalgebra homomorphism. The composition 
law, together with the next law, generalises the functor fusion law of folds. 
Hylo shift law or base change law If we have a natural transformation 
a : G -4 F, then 

<\a-aA^c\> G = (\a^aC-c\) F . (13) 

In fact, the statement can be strengthened: if c is recursive, then a C ■ c is 
recursive, as well. 

ft = a Fh • aC ■ c 
<*=> { a natural } 

h = a■a A■Gh ■ c 

•£=> { uniqueness property of hylos (5) } 

ft = (a • a A c) G 

It is worth pointing out that the laws stated thus far are independent of the 
existence of initial algebras. Only the following law makes this assumption. 
Fold / unfold law A fold after an unfold is a hylo. 

C«H(c> = («<-$ (14) 

From left to right we are performing fusion and thus deforesting an intermediate 
data structure. From right to left we are turning a control structure into a data 
structure. The fold/unfold law is a direct consequence of Theorem 1 and any of 
the fusion laws. 

5 Fusion 

In the previous sections we have introduced the fusion laws that we will now 
use to help us explain a collection of specific fusion techniques. We collectively 
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brand these techniques shortcut fusion, as they share the common characteristic 
of standardising the way data structures are recursively consumed and produced. 
Where shortcut fusion techniques differ is in their choice of recursion scheme. By 
using recursive coalgebras, we can clearly lay out and compare these approaches 
within the same framework. 3 This allows us to examine the relationships among 
these fusion approaches which are not readily apparent when examining their 
individual implementations. 

5.1 Warm-up: Type Functors 

We have seen in §2 that n is a functor, whose action on arrows is defined jia = 
din • aD- Using Theorem 1 and the hylo shift law (13) we can actually express 
Ha as a fold, an unfold or a hylo. 

net = <\in ■ a\) = (jm ■ a <— out\ = l\in <—a ■ out\) = [a- outj . 

In §5.5 we shall see a key use of n f° r stream fusion. For now, let us show a use 
of n with the base functor of parametrized List 

data Lab = Nil \ Cons (a, b ) . 

This is a higher-order functor of type L : C —> C c that takes objects to functors 
and arrows to natural transformations. In Haskell, we can make this datatype 
an instance of the Functor class: 
instance Functor (L a) where 
fmap f Nil = Nil 

fmapf (Cons (a, &)) = Cons ( a,f b) . 

We define this instance for the functor obtained by applying L to some type 
a. Haskell allows us to define this polymorphically for all a. The list datatype 
defined in terms of its base functor is List A = n( LA). The parametric type List 
is itself a functor, a so-called type functor, whose action on arrows is Haskell’s 
map function, defined in this setting by List / = /i(L/). Note that n expects a 
natural transformation and that L delivers one. 


5.2 Generalised foldr/build Fusion 

We now move on to the main target of our new setting: shortcut fusion. The 
original shortcut fusion technique is a fold-centric approach called foldr/build 
fusion [9]. As its name would suggest, its original intention was to provide fusion 
for list functions written in terms of foldr and an additional combinator build. 
In this section, we will explore the foundations of this technique. 

The mother of all fusion rules is algebra fusion (10). It allows us to fuse a 
hylo followed by an algebra homomorphism into a single hylo. It is similar to 

3 Previously these recursion schemes were only compatible for analysis by restricting 
the working category to one that is algebraically compact, such as Cpo L . 
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fold fusion in the sense that to use this law, we must construct a new algebra 
that satisfies a pre-condition. To illustrate this, the pipeline sum ■ filter odd can 
be expressed as a composition of two folds: (s) • flfD- The algebras s and f are 
given by 

f: LN(/r(LN)) -f /j(LN) 

f Nil = in Nil s : LNN — > N 

f (Cons (x, y)) = if odd x s Nil =0 

then in (Cons (x, y)) s (Cons (x,y)) = x + y . 
else y 

To be able to apply algebra fusion (10), we have to show that ( 0 ) is an algebra 
homomorphism from f to some unknown algebra sf. By hand, it is not hard to 
derive 0 f so that (s) • f = sf • F ( 0 ). 

Bf : LNN —> N 

Bf Nil =5 Nil 

sf(Cons (x,y)) = if odd x thens (Cons (x,y)) else y 

Since (s) replaces in by 6, we simply have to replace the occurrences of in in f 
by B. While this is an easy task to perform by hand, it is potentially difficult to 
mechanise as it requires analysis of the body of f; within it, the constructor in 
could easily have any name and conversely any function could be named in. Also, 
f could contain unrelated occurrences of in. This transformation is therefore not 
purely syntactic, but also involves some further analysis of the source program; 
this is not an approach we wish to pursue. 

The central idea of foldr/build fusion is to expose in so that replacing it by 
the algebra a is simple to implement. Consider fold fusion (2) again. 

h:a^b 

A fold ( —) is a transformation that takes an algebra to a homomorphism. Assume 
that we have another such transformation, say, fi that satisfies 

h ■ (3 a = (3b h : a -+ b . (15) 

The generalisation of foldr/build from lists to arbitrary datatypes, the so-called 
acid rain rule [19], is then 

<\a\) ■ (3in = (3 a . (16) 

Using (3 we expose in so that replacing in by a is achieved through a simple 
function application. Instead of building a structure and then folding over it, we 
eliminate the in and pass a directly to (3. The proof of correctness is painless. 

i«D •/?*«=/?« 

•£= { assumption (15) } 

M-.in^a 

But, have we made any progress? After all, before we can apply (16), we 
have to prove (15). Fold satisfies this property, but this instance of (16) is trivial: 
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(a*)-(in) = d<*D- Now, it turns out that in a relationally parametric programming 
language [16], the proof obligation (15) amounts to the free theorem [21] of the 
polymorphic type 

P : VA . (FA -► A) -► (B A) , (17) 

where B is some fixed type. In other words, in such a language the proof obli¬ 
gation can be discharged by the type checker. 

Returning to our example, we redefine filter odd as (A as . (| <p a )) in where 

4 >: (LN 6 —> 6) —> (LN 6 —» 6) 

(fa Nil = a Nil 

<j> a (Cons ( x , y)) = if odd a; then a (Cons ( x , y)) else y . 

We derived 4 > from the algebra f by abstracting away from in. The reader should 
convince herself that Xa . (\<f)a\) has indeed the desired polymorphic type (17). 
We can then invoke the acid rain rule (16) to obtain 

H • ( Xa ■ fl.<M) TO = ( Xa • (<£aD)s = • 

The example also shows that the acid rain rule is somewhat unstructured 
in that a hylo is hidden inside the abstraction A a. Without performing an ad¬ 
ditional beta-reduction, we can apply the rule only once. We obtain a more 
structured rule if we shift the abstraction to the algebra and achieve cata-hylo 
fusion: If r is a transformation that takes F-algebras to G-algebras satisfying 

hira^rb: Alg(G) <^= h : a -► b : Alg(F) , (18) 

then 

(l a D F • (t in <— c|) G m |r a <— c) G . (19) 

If r is A a . a, then this is just the fold/unfold law (14). For t a = a ■ a, this is 
essentially functor fusion (3). The proof of correctness is straightforward. 

(«Df • in *— c)g = d T a c )g 
= { algebra fusion (10) } 

M f '■ t in —> t a : Alg(G) 

= { assumption (18) } 

$0| F : in -+ a : Alg(F) 

The proof obligation (18) once again amounts to a theorem for free, this time of 
the polymorphic type 

t :V A . {F A ^ A) ^ (G A -> A) . 

Using cata-hylo fusion, the running example simplifies to 

(sD • fl^wD = fl^sD ■ 

We can now also fuse a composition of folds: 

d a D • dn m) • ... • (t„ in) ■ [c] = d(r„ •... • n) a <- c) . 
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This demonstrates how the rewrite rule is able to achieve fusion over an entire 
pipeline of functions. 


5.3 Generalised destroy/unfoldr Fusion 

The foldr/build brand of shortcut fusion, and its generalisation to algebraic 
datatypes, is fold-centric. This limits the kind of functions that we can fuse, 
simply because some functions such as zip or take are not folds, or are not 
naturally written as folds. We can dualise foldr/build fusion to achieve an unfold¬ 
centric approach, called destroy / unfoldr [18]. To illustrate, consider the simple 
pipeline take 5 • between, where take n takes n elements (if available) from a list. 
It can be written as an unfold after an initialisation step: take n = [tj ■ start n, 
where start n = (XI . (n, l)), and where the coalgebra t is given by 

type State a = (N, a) 
t : State (»(L a)) —> L a (State (p(L a ))) 
t (0, x) = Nil 

t(n + l,x) = case outxoi Nil —> Nil; Cons (a, y) —►. Cons (a, (n, y)) . 

Here we make explicit the notion that an unfold models the steps of a stateful 
computation. The coalgebra takes a state as an argument and uses it to produce 
a value and a new state. In this example, the state type pairs the input list with 
a natural number, enabling us to track the overall number of values produced. 
The number of elements to take, paired with the list where the values are to be 
taken from, forms the initial state. 

We can dualise the acid rain rule to fuse the pipeline. If f3 is a transformation 
that satisfies 


/3c = (3d-h <=> h : c d , (20) 

then 

f3 c = /3 out ■ (c). (21) 

Previously we exposed in, now we expose out. To apply the dual of acid rain we 
redefine take n as (A c . [7 c] • start n) out, where 

7 : (c —> L a c) —> (State c —> L a (State c)) 

7 c (0, x) = Nil 

7 c (n, x) = case c x of Nil —> Nil ; Cons (a, y) —> Cons (a, (n — 1, y)) . 

The transformation 7 is derived from t by abstracting away from out. We can 
now tackle our example: 

(A c . [7 cj • start 5) out ■ [bj = (A c . [7 cj • start 5) b = [7 b] • start 5 . 

The proof obligation (20) corresponds to the free theorem of 


p:VC .(C-*FC)^(C ^ D) , 


( 22 ) 
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where D is fixed. And, indeed, A c . [7 cj • start 5 has the required type. 

Similarly, we can dualise our more structured cata-hylo fusion to achieve 
hylo-ana fusion: If r is a transformation that takes recursive F-coalgebras to 
recursive G-coalgebras satisfying 

h-.rc^Td: Rec(G) <^= h : c -> d : Rec(F) , (23) 

then 

(a <— r c) G = '(« <- t««£)g ‘Mi . (24) 

This time the proof obligation (23) cannot be discharged by the type checker 
alone as r has to transform a recursive coalgebra into a recursive coalgebra! As 
an aside, the new rule cannot handle our running example as the two unfolds 
are separated by the initialisation function start. 

Our example has focused on fusing the list parameter of take, yet if we 
admit to the fact that natural numbers are an inductive datatype, then take 
is really a function that consumes two data structures. The aforementioned zip 
is another function that consumes two data structures, and therefore has the 
potential to be fused with both of these inputs. Let us employ the expression 
zip ■ ( between x between) as another example that can be written in terms of 
unfolds: [3] ■ ([b] x |bj). The algebra 3 is given by 

3 : (/x(L 01), /x(L d 2 )) -> L (ai, a 2 ) (p(l di), p(l 02)) 

3 (xi, xf) ~ case ( out Xi, out x-f) of 

(Cons (di, 61), Cons (d 2 , & 2 )) Cons ((ai, d 2 ), (61, & 2 )) 
otherwise —> Nil . 

Our rules (21) and (24) are not applicable as we have two producers to the right 
of zip. Now, to fuse such a function, we need to employ parallel hylo-ana fusion: 
If t satisfies, 

h x h 2 ■■ t (ci, c 2 ) —> r (rfi, da) : Rec(G) 

<= hi : ci —> d\ : Rec(Fi) A ha : c 2 —> d 2 : Rec(F 2 ) , (25) 

then 

(a <— r (ci, c 2 )D g = (a <— t (out, out)\) G ■ (|ci] Fi x [c 2 ] F2 ) • (26) 

Using this rule, we are now able to fuse the zip example: 

1C (out, out)} ■ ([bj x [bj) = [C (b, b)3 , 
where the transformation ( is defined 

£ : (b 1 —> L ai bi, b 2 —> L a 2 6 2 ) —> (61, & 2 ) —> L (ai, aa) (bi, 62) 

C (ci, c 2 ) (xi, X2) = case (ci xi, c 2 a; 2 ) of 

(Cons (di, 61), Cons (d 2 , b 2 )) —> Cons ((di, d 2 ), (61, 6 2 )) 
otherwise —> Nil . 

The proofs of correctness for (parallel) hylo-ana fusion are contained in extended 
version of this paper. 
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5.4 Church and Co-Church Encodings 

In the two previous sections we have studied generalisations of foldr/build and 
destroy / unfoldr fusion. We have noted that (| — D generalises the list function 
foldr, and, likewise, [—] generalises unfoldr. We have been silent, however, about 
their counterparts build and destroy. It is time to break that silence, and in the 
process, provide a fresh perspective on recursive datatypes. For simplicity, we 
assume that we are working in Set. 4 

Consider again the polymorphic type of (3 (17) repeated below. 

V A .(F A-> A) ^ (B ^ A) M B -► (VA . {FA -* A) -> A) 

We have slightly massaged the type to bring B to the front. The universally 
quantified type on the right is known as the Church encoding of /./F [4]. The type 
is quite remarkable as it encodes a recursive type without using recursion. One 
part of the isomorphism fiF = V A . (F A —* A) —> A is given by the acid rain 
rule (16). The following derivation, which infers the isomorphisms, makes this 
explicit—the initial equation is (16) with the arguments of (3 swapped. 

Va. <\a\>(Pbin) = f3ba 
4=> { change of variables (3 b = 7 } 

V o ■ d«D (7*™) =ia 

4=> { extensionality } 

Afl.|«D(7 in) = 7 

4=> { define toChurch i = Aa.(a|i} 

toChurch (7 in) = 7 
4=>- { define fromChurch 7 = 7 in } 

toChurch (fromChurch 7) = 7 

The isomorphism toChurch, creates a function whose argument is an algebra and 
which folds that algebra over the given data structure. Its converse fromChurch, 
commonly called build, applies this function to the in algebra. Going back and 
forth, we get back the original structure: fromChurch ( toChurch s) = s. This is 
the other part of the isomorphism, which follows directly from fold reflection. 

As to be expected, everything nicely dualises. The polymorphic type (22) 
gives rise to the co-Church encoding. 

VC .(C^FC)^(C^D) s (3C.(C^FC) x C) ^ D 

Think of the co-Church encoding 3C . (C — > F C) x C as the type of state 
machines encapsulating a transition function C —> F C and the current state C. 

The conversion to (co-) Church-encoding types are central to the concept of 
shortcut fusion. By changing representations to one with the recursion “built- 
in”, we can write our transformations as non-recursively-defined (co-)algebras. 
Unlike recursive programs, compositions of these (co-)algebras can be optimised 


The development can be generalised using ends and coends [14]. 
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by the compiler to remove any intermediate allocations. All that remains is for 
the programmer to instruct the compiler to remove any unnecessary conversions, 
i.e. cases of toChurch ■ fromChurch. Removing these transformations preserves 
the semantics of the program because we can prove the isomorphism between 
these representations. More importantly, however, prevents us from producing 
a data structure only to immediately consume it. The co-Church encoding also 
underlies the original formulation of stream fusion, which we consider next. 

5.5 Stream Fusion 

The foldr/build, flavour of fusion is fold-centric, in that it requires all functions 
that are intended to be fusible to be written as folds; similarly, destroy/unfoldr 
is unfold-centric. The boundaries of these world views are fuzzy. A zip can be 
written as a fold, the snag is that only one of the two inputs can be fused [9, 
§9]. Along a similar vein, a filter for the odd natural numbers, which we wrote 
before as a fold, can also be written as an unfold: [f| where 

f :/i(LN) LN(/r(LN)) 

f x = case out x of Nil —> Nil; Cons (x,y) —» if odd x then Cons (x, y) else f y . 

The coalgebra f is recursive and thus theoretically fine, but it is also recursive in 
its definition and this is a practical problem. A coalgebra must be non-recursively 
defined for it to be fused with others. We have two definitions and are caught 
between two worlds; is it possible to free ourselves? 

Perhaps surprisingly, the answer is yes. Let us first try to eliminate the re¬ 
cursion from the definition above—the rest will then fall out. The idea is to 
use a different base functor, one that allows us to skip list elements. We draw 
inspiration from stream fusion [5] here: 

dataS a b = Done \ Yield (a, b) \ Skip b . 

instance Functor (S a) where 
fmap f Done = Done 

fmap f ( Skip b) = Skip (/ b) 

fmap /{Yield (a, b )) = Yield ( a,f b) 

The filter coalgebra can now be written as a composition of out with 

f: SN6 —► SN6 

f Done = Done 

f (Skip y) = Skip y 

f (Yield (x, y)) = if odd x then Yield (x, y) else Skip y . 

So, filter = [f • out}. Something interesting has happened: since f is a natural 
transformation, we also have filter = (| in ■ f D. We are unstuck; filter is both a fold 
and an unfold. Moreover, it is an application of a mapping function: filter = /if. 

In general, consumers are folds, transformers are maps, and producers are 
unfolds. An entire pipeline of these an be fused into a single hylo: 

d«D ’ .• [cj = (|a • ai. a n <— cD . 
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Inspecting the types, the rule is clear: 

(a| c uai 


- rFq - 


- mF i 


mF„-i 


/*f „ 


In a sense, the introduction of Skip keeps the recursion in sync. Each transfor¬ 
mation consumes a token and produces a token. Before, filter possibly consumed 
several tokens before producing one. We are finally in a position to deal with the 
example from the introduction, written in terms of the combinators we have 

ds|) • p(msq) ■ £t(f odd) ■ [bj = (|s • msq • f odd <- b) . 

Utilising streams in this fashion is an instance of data abstraction; although 
we wish to present the List type using p(L a), we intend to do all the work 
using /i(Sa). We have functions and to convert to and from streams, 
respectively. They are defined as an algebra and a coalgebra that allow us to 
consume streams using a fold and produce them using an unfold: 

-^-S : S a (p(L a)) —► (p(L a)) 

^— S Done = in Nil 

~\ —S ( Skip xs) = xs 

■s— S (Yield (x, xs)) = in (Cons (x, xs)) 

—'■S : p(L a) —> S a (p(La)) 

—(in Nil) = Done 

—(in (Cons (x, xs))) = Yield (x, xs) . 

We must prove that our stream implementations, together with the con¬ 
version functions, fulfil the same specification as the analogous functions over 
/u(L a) (cf. Lemma 1 and Theorem 3 in [23]). This is called the data abstraction 
property. In our framework, this obligation is expressed as a simple equality be¬ 
tween a conventional list function definition and its associated stream version 
composed with our conversion functions. For example, for filter we must prove 

filter = fl-i-SD • pf ■ , 

Because we can phrase these functions as folds, unfolds, and natural transfor¬ 
mations, the proof is straightforward, using the laws we have set out in previous 
sections. We leave it as an exercise to the reader. 

Just as for lists, every datatype can be extended with a Skip. Although 
stream fusion is the first to make use of this augmentation, we note its relation to 
Capretta’s representation of general recursion in type theory [1], which proposes 
adding a “computation step” constructor to coinductive types. 


6 Related Work 

Wadler first introduced the idea of simplifying the fusion problem with his defor¬ 
estation algorithm [22]. This was limited to so-called treeless programs, a subset 
of first-order programs. The fusion transformation proposed by Chin [3] gener¬ 
alises Wadler’s deforestation. It uses a program annotation scheme to recognise 
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the terms that can be fused and skip the terms that cannot. Sheard and Fegaras 
focus on the use of folds over algebraic types as a recursion scheme [17]. Their 
algorithm for normalising the nested application of folds is based on the fold fu¬ 
sion law. Their recursion schemes are suitably general to handle functions such 
as zip that recurse over multiple data structures simultaneously [6]. 

Gill et al. first introduced the notion of shortcut fusion with foldr/build 
fusion [9] for Haskell. This allowed programs written as folds to be fused. It 
was subsequently introduced into the List library for Haskell in GHC. Takano 
and Meijer [19] provided a calculational view of fusion and generalised it to 
arbitrary data structures. It generalised the fusion law by using hylomorphisms 
and also noted the possibility of dualising foldr/build fusion. They worked in the 
setting of Cpo, however, where hylomorphisms do not have unique solutions, 
only canonical ones. Takano and Meijer claimed that, even when restricted to 
lists, their method is more powerful than that of Gill et al. as theirs could fuse 
both parameters of zip. This was incorrect, and the need for an additional parallel 
rule for zip was pointed out later by Hu et al. [11]. Their extension is what we 
present as the parallel hylo-ana rule. 

Svenningson provided an actual implementation of destroy/unfoldr fusion [18], 
where he showed how filter-like functions could be expressed as unfolds. Sven¬ 
ningson did not, however, solve the issue of recursion in the coalgebras of such 
functions, which could therefore not be fused even though they could be written 
as unfolds. This was addressed by Coutts et al., who presented stream fusion [5], 
which introduced the Skip constructor as a way to encode non-productive com¬ 
putation steps, similar to Capretta’s work on encoding general recursion in type 
theory [1]. 

The correctness and generalisation of fusion has been explored in many dif¬ 
ferent settings. In addition to the work of Takano and Meier, Ghani et al. gen¬ 
eralised foldr/build to work with datatypes “induced by inductive monads”. 
Johann and Ghani further showed how to apply initial algebra semantics, and 
thus foldr/build fusion, to nested datatypes [12]. Voigtlander has also used free 
theorems to show correctness, specifically of the destroy/build rule [20]. 


7 Conclusions 


We have presented a framework that has allowed us to bring three fusion tech¬ 
niques into the same setting. We have exploited recursive coalgebras and hylo¬ 
morphisms as ‘the rug that ties the room together’. This enabled us to formally 
describe and reason about these fusion techniques. In doing so, we have exposed 
their underlying foundations, including the importance of Church and co-Church 
encodings. The fact that our hylomorphisms have unique solutions plays a cen¬ 
tral role. The knock-on effect is that we gain clear, short proofs thanks to the 
calculational properties available to us. 
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